home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group95b.txt
/
000026_icon-group-sender _Wed May 24 16:21:25 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-09-18
|
2KB
Received: by cheltenham.cs.arizona.edu; Wed, 24 May 1995 17:39:22 MST
From: mitch@roll.csd.sgi.com (Tom Mitchell)
Message-Id: <199505242321.QAA14130@roll.csd.sgi.com>
Subject: Re: icon notes [Re: Is there such a language...]
To: gep2@computek.net
Date: Wed, 24 May 1995 16:21:25 -0700 (PDT)
Cc: icon-group@cs.arizona.edu
In-Reply-To: <9505241140.AA03879@ns1.computek.net> from "gep2@computek.net" at May 24, 95 11:40:00 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
Content-Length: 968
Errors-To: icon-group-errors@cs.arizona.edu
>
> >I agree that Icon can run circles around C and similar languages. And I'm
> all for working smarter and charging higher rates for my time. :-)
>
> >But...
> Does the Icon compiler produce native (machine) code? Execution
> performance is still an issue for many, although I agree that it
> is becoming *less* of an issue.
>
Interpreted languages have many advantages over "native
code".
Speed need not be an advantage of "native code". An
interpreter that is structured and sized to behave well in
a cache can run faster than native code that does not fit.
It is sort of the old religion of CISC vs. RISC so lets avoid
that distraction.
But perhaps more important are two things:
1) The portability and availability that an interpreter can
provide. In this regard Perl is just such a win.
Regardless of the hardwre or OS system only the interpreter
need be ported.
2) The richness of the language and the abstraction it
provides.